The present disclosure relates to computer runtime systems, and specifically composite applications implemented in computer runtime systems.
The process of building complex business logic using a set of components, such as portlets, can be a tedious endeavour. First, individual components are deployed sequentially. Then, the deployed individual components are arranged on a customer's staging system as desired. Finally, component interaction and access control are defined according to the business logic to be implemented. The above steps require active involvement of application developers, portal administrators and persons with the necessary business domain skills.
To simplify the aforementioned process, composite applications, such as composite portal applications (or portal server applications), were introduced as a key strategy for implementing meaningful business value within a Service Oriented Architecture (SOA). Composite portal applications provide a flexible framework to produce very complex websites with reasonable effort. The basic functional units of a composite portal application are application components (or portlets, when specifically referring to the functional units of a composite portal application). The composite portal application aggregates the output of the individual portlets to an output which can be rendered in a browser. This aggregation of content is an important feature of composite portal applications, since the composite portal application effectively integrates the user interface (UI) of independent portlets without the need to write any integration code.
Business analysts and application designers can leverage composite applications to assemble complex business logic easily from individual application components, such as JAVA® classes (JAVA® is a registered trademark of Sun Microsystems, Inc., portlets, Enterprise JAVA® Beans (EJBs) (EJB is a trademark or registered trademark of Sun Microsystems, Inc.), processes, Plain Old JAVA® Objects (POJOs), or other code artifacts. Portals expose a user to multiple services in a single interface. Composite applications allow the user to interact with these multiple services. Composite applications do away with multiple User Interfaces (UIs) and permit improved data connectivity. Composite applications achieve this by making functionality and data independent from an architecture. As a result, users can, on their own, define, create and manage composite portal applications. The use of a composite application delivery model emphasizes a move towards a strongly business-driven usage model with plug-ability and fewer dependencies on support by system administrators.
Modern composite portal applications typically have a considerable number of application components. Furthermore, application components can be added to an existing aggregation of application components to produce even more sophisticated composite applications. Each application component in the aggregation must be executable on the designated target system to which the composite portal application is deployed. One example of a target system is the JAVA® Platform, Enterprise Edition (J2EE), which provides a programming platform for developing and running distributed multi-tier architecture JAVA® applications. However, other target systems are conceivable as well. A complex composite portal application comprises manifold application component types, which are all suited together in a coherent composite application produced by a large application development team.
U.S. Published Patent Application US2006/0036993 A1 describes a system and method for developing a composite portal application by creating a portal application archive, and for automatically deploying the portal application archive into a portal server environment. A portal application is a specific type of application. In particular, a portal application is a collection of pages, portlets, policies, and roles. According to an embodiment of the method in accordance with the above mentioned document, a composite portal application is provided to a portal server environment as a portal application archive. The portal application archive includes (i) all application components in machine-readable code for forming the composite portal application, and (ii) an application component assembly descriptor in machine readable code that specifies how the application components need to be assembled such that the composite portal application is correctly deployed into the portal server environment.
In order to deploy the composite portal application into the portal server environment, the portal application archive is provided to a deployment mechanism within the portal server application environment. The deployment mechanism enables the deployment of the portal application archive into the portal server environment. Further, the application component assembly descriptor included in the portal application archive is evaluated by means of the deployment mechanism. The application components are automatically deployed into respective parts of the portal server application environment according to information included in the application component assembly descriptor.
The application component assembly descriptor can be implemented in the form of an Extensible Markup Language (XML) descriptor file and includes meta-data that describe how each particular application component of the composite portal application is to be used within the composite portal application. Each piece of meta-data is evaluated accordingly via the deployment mechanism described above. The meta-data provided by the application component assembly descriptor therefore provides added value for the composite application with respect to the standard JAVA® J2EE. While JAVA® supports coding, deployment, and life cycle aspects of composite portal applications, the meta-data can be regarded as comprising the logic focus description language on top of JAVA® and can be implemented in the form of XML.
The application component assembly descriptor can be viewed as a template, which describes how to create/instantiate one or multiple instances of the composite application. The instantiation results in a set of portlet instances and page instances. According to the current state in the art, a composite application's runtime environment creates all the resources that are needed to represent the desired composite application. Such resources can be component instances, Portal pages, code instances, portlet instances, and other types of layout elements. The current approach provides a very efficient way to generate many similar Portal applications, while using a common template definition.
However, the drawback of the described template instantiation is that the instantiation process creates real resources in the portal. These real resources consume memory and limit the number of possible instances that can be used. According to some use-cases, the consequences of such a drawback do not have a significant impact (e.g., when there are only a limited number of teamroom applications on a system). However, there are use-cases, where the fact that individual copies of the same portal resources are needed for each instance is a severe limitation. One exemplary scenario where such severe limitations occur is in the use of a web conference application or an “activities” application, which will need to scale to a considerably higher number of supported instances. As a result, there can potentially be thousands of scheduled web conferences, while only a few web conferences will be able to take place concurrently. Thus, in summary, a limitation of the existing approach is that the template is used to permanently generate new instances of the composite application. For scalability reasons, such an approach is not suitable if a large number of instances of the same template are required.